Because the base bones of business works in enterprises are being computerized, most of the enterprises come to have large-scaled databases that hold a great amount of data used in those business works. Those data are important data in terms of the business works, so that it is absolutely essential to prevent those data from being leaked to outside also in terms of protecting personal information. Therefore, it is common to encrypt the data to be held in such large-scaled databases.
A database can be considered as an aggregate of a large number of tables. “Natural joining” herein means to join two tables into one by integrating columns when there are the columns showing same data in the two tables. Hereinafter, a typical method depicted in Non-Patent Document 1 and the like executed for naturally joining two tables in a database in which the held data is encrypted (referred to as an encrypted database hereinafter) will be described.
FIG. 18 is an explanatory chart showing the structure of an encrypted database management system 901 according to a typical technique regarding the encrypted database. The encrypted database management system 901 is constituted with an encrypted database client 910 and an encrypted database server 950 mutually connected via a LAN (Local Area Network) and the like.
The encrypted database client 910 has the structure as a typical computer device. That is, the encrypted database client 910 includes a central processing control module (CPU: Central Processing Unit) 911 that is the main unit for executing computer programs, a storage module 912 for storing data, an input module 913 for accepting operations done by the user, and an output module 914 for presenting processing results to the user, and a communication module 915 for performing data communications with other computers.
In the central processing control module 911, a column encrypting unit 921 and an encrypted table natural joining request unit 922 are structured to execute respective functions to be described later as each computer program according to operation commands from the user. Further, in the storage module 912, each of individual private key 931a and private key′ 931b used in processing to be described later is stored. Furthermore, a table A932 and a table B933 to be the targets of encryption and natural joining are inputted to the input module 913.
The encrypted database server 950 also has the structure as a typical computer device. That is, the encrypted database server 950 includes a central processing control module 971 as the main unit for executing computer programs, a storage module 952 for storing data, and a communication module 953 for performing data communications with other computers.
In the central processing control module 971, an encrypted table natural joining unit 963 and a data receiving unit 964 are structured to execute respective functions to be described later as computer programs according to operation commands from the encrypted database client 910.
Further, an encrypted table A941 and an encrypted table B942 which are encryptions of each of the tables A933 and B934, as well as a public key pkey972a and a public key pkey′972b corresponding, respectively, to the private key key931a and the private key key′931b of the encrypted database client 910 received by the data receiving unit 964 from the encrypted database client 910 are stored in the storage module 952.
FIG. 19 is an explanatory chart for describing the functions of the column encrypting unit 921 shown in FIG. 18 in more details. The column encrypting unit 921 includes an encrypting function 921a and a table update function 921b. The encrypting function 921a encrypts a specific column (referred to as column a) of the table A932 by using the private key key931a and outputs a ciphertext 943. The table update function 921b outputs the table in which each data of the column a is replaced with the ciphertext 943 as an encrypted table A941, and transmits it to the encrypted database server 950. In the encrypted database server 950, the data receiving unit 964 stores those to the storage module 952.
The column encrypting unit 921 also outputs an encrypted table B942 in which a specific column (referred to as column b) of the table B933 is replaced with a ciphertext by using a private key key′931b, and records it to the storage module 912. Note that a table identifier 932a=“A” of the encrypted table A941, a column identifier 932c=“a” of the column a, a table identifier 933a=“B” of the encrypted table B942, and a column identifier 933c=“b” of the column b are not the targets of encryption, respectively, so that those are stored to the storage module 952 along with the encrypted table A941 and the encrypted table B942 and also stored to the storage module 912 of the encrypted database client 910 at the same time.
FIG. 20 is an explanatory chart for describing functions of the encrypted table natural joining request unit 922 shown in FIG. 18 in more details. The encrypted table natural joining request unit 922 issues a natural joining request text 971 for giving a command to naturally join the encrypted table A941 and the encrypted table B942 by having the column a and the column b as the key based on the table identifier 932a=“A” of the encrypted table A941, the column identifier 932c=“a” of the column a, the table identifier 933a=“B” of the encrypted table B942, and the column identifier 933c=“b” of the column b, and transmits it to the encrypted database server 950. In the encrypted database server 950, the data receiving unit 964 upon receiving it operates the encrypted table natural joining unit 963 according to the natural joining request text 971.
FIG. 21 is an explanatory chart for describing functions of the encrypted table natural joining unit 963 shown in FIG. 18 in more details. The encrypted table natural joining unit 963 includes a decrypting function 963a, a natural joining function 963b, and a re-encrypting function 963c. The decrypting function 963a decrypts the data of the column a and the column b encrypted in the encrypted table A941 and the encrypted table B942 by using the public key pkey972a and the public key pkey′972b corresponding to the private key key931a and the private key key′931b, respectively, to return the tables to the table A932 and the table B933 which are in the state before being encrypted.
The natural joining function 963b performs natural joining of the table A932 and the table B933 by having the column a of the table A932 and the column b of the table B933 as the key according to the command given by the natural joining request text 971. The re-encrypting function 963c re-encrypts the column a (column b) as the key of the joined table A932 and the table B933, and returns the acquired encrypted table A×B981 to the encrypted database client 910. The public key pkey972a is used herein for the re-encryption. However, other encrypting keys may also be used.
FIG. 22 is an explanatory chart showing an example of the table A932 before being encrypted by the encrypted database management device 910 shown in FIG. 18. In the example shown in FIG. 22, the corresponding relation between the card numbers corresponding to the respective user names are shown by setting the first column 932a of the table A932 as “user names” and the second column 932b as “credit card numbers”.
The encrypted database management device 910 encrypts the target data with an encryption function enc such as Hash function by using the private key “key” for the data to be concealed. FIG. 23 is an explanatory chart showing the encrypted table A941 that is in a state acquired by encrypting the table A932 shown in FIG. 22 done by the column encrypting unit 921 shown in FIG. 18. Here, the second column 932b “credit card numbers” is taken as the target to be concealed, and the data acquired by encrypting a plain text m with an encrypting key is expressed as enc (key, m).
The private key “key” is inherently given to each table. Encryption is definite, so that the value of enc (key, m) is uniquely determined when the plain text m and the private key “key” are settled. Note, however, that the encryption function enc is desirable to be an irreversible function such as a Hash function.
With this, even when the encrypted table A941 shown in FIG. 22 is leaked to the outside, the credit card number is not leaked unless the private key “key” is also leaked. Further, for the proper user having the private key “key”, the table can be searched by using the credit card number. For example, when searching the user having the credit card number “12334”, the search can be done by using enc (key, 12334).
As technical documents related thereto, there are following documents. Depicted in Patent Document 1 is an encrypting/decrypting device which can transmit/receive encrypted information containing key recovery information which can recover a decryption key even when the user loses the decryption key in transmission/reception of encrypted data. Depicted in Patent Document 2 is a natural joining high-speed calculation method which enables high-speed search of a table that is acquired by joining two tables.
Depicted in Patent Document 3 is a joining size evaluation method which is capable of decreasing the calculation cost required for performing equi-joining of databases. Depicted in Patent Document 4 is a database inquiry system which guides the user so that the user can generate a proper SQL text. Depicted in Patent Document 5 is an encryption system which certifies the uniformity of the plaintexts of a plurality of ciphertexts without disclosing private information through generating information series for certifying the plurality of ciphertexts. Depicted in Patent Document 6 is a database system which enables changes in the encrypting key and encryption algorithm during operation through further encrypting the generated encrypting key with another key.
Depicted in Non-Patent Document 1 is an existing technique regarding the encrypted database described above. Depicted in Non-Patent Document 2 is a typical content regarding a database including natural joining of tables.    Patent Document 1: Japanese Unexamined Patent Document 2000-267565    Patent Document 2: Japanese Unexamined Patent Document Hei 02-132559    Patent Document 3: Japanese Unexamined Patent Document Hei 10-124533    Patent Document 4: Japanese Patent Application Publication Hei 09-510565    Patent Document 5: Japanese Unexamined Patent Document Hei 11-065441    Patent Document 6: Japanese Unexamined Patent Document Hei 11-143780    Non-Patent Document 1: Paul Needham et al., “Oracle Advanced Security Technical White Paper”, Oracle Japan, June 2007, “Searched Sep. 3, 2010”, Internet <URL: http://otndnld.oracle.co.jp/products/database/oracle11g/pdf/twp_security_db_advancedsecurity—11gR1.pdf>    Non-Patent Document 2: Hiroyuki Kitagawa, “Database System”, Shokodo, July 1996
With the database, not only necessary data is extracted from a vast amount of data but also a plurality of tables are joined frequently by SQL (Structured Query Language) commands and the like. Even for the encrypted data, it is naturally desired to be able to do calculations for performing natural joining of the tables easily without threatening the security.
However, the encrypting key “key” is given inherently to each table as described above, so that different encrypting keys are given to different tables. Thus, the same data on different tables become different data when encrypted with different encrypting keys. Therefore, in order to perform a calculation for joining different tables by having the data encrypted by the column encrypting unit 921 as the key by using the encrypted database management system 901 shown in FIG. 18, it is necessary to join the data by decrypting it once as described above.
This will be described more specifically. FIG. 24 is an explanatory chart regarding an example of a case where the encrypted database management device 901 shown in FIG. 18 performs a calculation for naturally joining a plurality of encrypted tables A941 and B942. FIG. 24A shows the encrypted table A941, FIG. 24B shows the encrypted table B942, and FIG. 24C shows an encrypted table A×B981, respectively. The encrypted table A941 shows the corresponding relation between each user and corresponding card numbers, in which the first column 932a is “user names” and the second column 932b is “credit card numbers”. The second column 941b is encrypted by using the private key key931a. The encrypted table B942 shows the expiration dates of each card, in which the first column 933a is “credit card numbers” and the second column 933b is “credit card expiration dates”. Further, the first column 942a is encrypted by using the private key key′931b. 
When the administrator of the database wishes to know the corresponding relation between the “user names” and the “credit card expiration dates”, the administrator issues the natural joining command text 971 by the encrypted table natural joining request unit 922 to naturally join the encrypted table A941 and the encrypted table B942 by having the “credit card numbers” of the columns 941b and 942a as the key. By this processing, it is expected to acquire the encrypted table A×B981 which contains three columns, such as the first column 981a “user names”, the second column 981b “credit card numbers”, and the third column 981c “credit card expiration dates”.
However, the encrypted table A941 and the encrypted table B942 are encrypted with the different private keys key931a and key′931b, so that the data thereof are different data because of the different encrypting keys even the data at the stage of being in plaintexts are the same data. Thus, the encrypted table natural joining unit 963 cannot use the encrypted data directly as the key for natural joining. In order to perform this processing, it is necessary to perform processing for decrypting the columns 941b and 942a by the decrypting function 963a shown in FIG. 21.
For the processing, the public keys pkey′972a and pkey′972b corresponding to the respective private keys key931a and key′931b for the encrypted table A941 and the encrypted table B942 are required. By using the public keys, it is possible to decrypt the columns 941b and 942a for performing the processing. However, during the processing, the decrypted plaintext data is stored in the device, so that there may be a risk of having leakages of the plaintext data during that time.
FIG. 25 is an explanatory chart regarding an example of performing a calculation for naturally joining an encrypted table C1001 and an encrypted table D1002 encrypted by utilizing key=key′, i.e., the same encrypting key “key”, in order to overcome the foregoing issues. FIG. 25A shows the encrypted table C1001, the FIG. 25B shows the encrypted table D1002, and FIG. 25C shows an encrypted table C×D1003, respectively. This encrypting key may be of a public key type or of a common key type.
The encrypted table C1001 shows the corresponding relation between each user and corresponding card numbers, in which the first column 1001a is “user names” and the second column 1001b is “credit card numbers”. The second column 1001b is encrypted by using the encrypting key “key”. The encrypted table D1002 shows the expiration dates of each card, in which the first column 1002a is “credit card numbers” and the second column 1002b is “blacklist registered dates”. Further, the first column 1002a is encrypted by using the same encrypting key “key” as that of the table C1001.
When the encrypting key “key” is the same, the data after being encrypted are the same provided that the data before being encrypted regarding the second column 1001b of the encrypted table C1001 and the first column 1002a of the encrypted table D1002 are the same. Therefore, it is possible to acquire the encrypted table C×D1003 by naturally joining the encrypted table C1001 and the encrypted table D1002 directly without utilizing the decrypting function 963a. However, at the same time, this means that even an improper user who does not have the encrypting key “key” can perform the processing for acquiring the encrypted table C×D1003 by naturally joining the encrypted table C1001 and the encrypted table D1002 by having the encrypted data as the key. This is not desirable for managing the encrypted database.
That is, desired is an encrypted database management device with which a plurality of tables by having the encrypted data as the key can be naturally joined by the user who has the proper encrypting key without performing processing for decrypting the encrypted data but with which the encrypted data cannot be naturally joined by illegitimate users who do not have the proper encrypting key. In addition, it is also required to suppress a large increase in the calculation amount for performing the processing since the database handles a vast amount of data.
Each of the above-described Patent Documents and Non-Patent Documents is not designed to overcome such issue, so that techniques capable of overcoming such issue are not depicted therein naturally.
An object of the preset invention is to provide an encrypted database management system, a client, a server, a natural joining method, and a program thereof, which are capable of naturally joining a plurality of tables of an encrypted database by having the encrypted data as the key without performing processing for decrypting each element of the data and without largely increasing the calculation amount.